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Introduction 

Livelnventor is an interactive development 
environment for robot autonomy developed at 
NASA Ames Research Center. It extends the 
industry-standard Openlnventor graphics library 
and scenegraph file format to include kinetic and 
kinematic information, a physics-simulation 
library, an embedded Scheme interpreter, and a 

distributed communication system. 
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Background and motivation 

Reliable, robust autonomy is crucial for long 
distance and long duration unmanned 
exploration of the Martian surface, but autonomy 
is difficult to put on mission for a number of 
practical reasons^ Like any engineers, autonomy 
developers require a platform on which to test 
and .debug their, product. For .Mars, missions this 
generally means one of two unique, identical 
rovers: one that flies and one that stays on the 
ground, shared by all hardware and software 
teams for test and simulation. Autonomy 
development and testing generally needs a 
complete, operational rover and must wait for all 
other teams to complete their work before really 
being able to begin theirs. Operating the rover in 
a sandbox for autonomy development and testing 
is an- expensive, labor-intensive and time- 
consuming proposition. Even then, a duplicate 
rover in a sandbox is only an approximation of a 
rover in Martian gravity, atmosphere and soil. 
Compounding the problem is nature of the Mars 


launch window. The heavens impose the hardest 
of deadlines: a mission can only be launched 
during a short window -every 26 months and 
projects must meet this schedule at all costs. If 
there axe delays in the project’s critical path the 
only alternative is to cut things at the end; 
fallback modes in which the rover can operate 
without autonomy are always provided for in 
case autonomy fails or the schedule slips; these 
become the mission baseline. 

One part of the solution to this problem 
is to enable autonomy development much earlier 
in the process, early enough to influence the final 
design. The purpose of Livelnventor is to 
provide a software environment in which jo vers 
can be very quickly modeled,* and their physical 
interaction with the world simulated and 
visualized, at a level of abstraction appropriate 
for autonomy developers, with accurate masses, 
joints, actuators, sensors, terrain, gravity and 
atmospheric conditions. 

Another part of the solution is to 
increase the number of autonomy developers 
available to work on the problem. Livelnventor 
has been assembled from open-source and COTS 
components so that it can be easily and cheaply 
distributed to academic institutions, enabling 
professors and students 'to easily develop 
software for NASA-relevant challenge problems. 

Architecture of Livelnventor 

Livelnventor is an application that integrates a 
physically-based simulation library with a 3-D 
rendering environment, a scripting language, and 
a distributed communication system, packaged 
within a graphical user interface. 

Livelnventor was built by extending 
Openlnventor, the graphics library developed by 
SGI [1]. Inventor, models three-dimensional 
solids using a scenegraph, an ordered acyclic 
graph in which nodes represent graphics entities 


or operations. Actions (loading a scenegraph 
from a file, rendering the scenegraph, searching 
it) are accomplished by traversing scenegraphs 
and changing state as each node is traversed. 
Livelnventor extends the set of nodes defined by 
Inventor by introducing nodes that represent 
kinematic and kinetic parameters like mass and 
inertia tensor, constraints (joints) between bodies 
like hinges and springs, geometrical collision 
models that may differ from the rendered 
graphical models, and material types and their 
interactions like friction and collision elasticity. 
Livelnventor follows Openlnventor’s rules for 
extending the node and state definitions, so 
Livelnventor nodes behave just like regular 
Openlnventor nodes, e.g. they are read in with 
the standard read-from-file command, they are 
written with the standard write-to-file command, 
etc. Also, the node definitions can be compiled 
to a dynamically linked library (DLL) so they 
can be linked into any existing inventor 
application. 

When the Livelnventor nodes are 
loaded they cause the appropriate dynamic mass 
objects, constraints, collision models and 
materials to be created in the physical simulation 
world. The physics library used in Livelnventor 
is currently Vortex, sold by Critical Mass Labs. 
Autonomy developers' can use the embedded 
Scheme interpreter to communicate with the 
simulated rover or the environment without 
having to compile and link C or C++ code. 
Livelnventor uses the Gambit Scheme library 
[2]. Gambit is written in C and includes both a 
Scheme interpreter and Scheme-to-C compiler, 
making it very easy to call Scheme code from the 
C++ environment or call C functions from the 
Scheme environment. 

Often autonomy developers have 
existing systems written in a language other than 
Scheme, on operating systems other than 
Microsoft Windows NT, and want to develop 
and test their code against a simulated rover 
without having to either recode in Scheme or 
have to link their C/C++ code into a large 
executable. Autonomy developers with existing 
large systems can use Ensemble, an open-source 
publish-subscribe message passing system from 
Cornell University to communicate with the 
simulated rover and its environment [3]. 
Ensemble is robust, has a small memory 
footprint, has been ported to most common 
operating systems (Windows, Mac, most UNIX 
implementations) and has a simple API. 
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Figure 1. Livelnventor Architecture 
Design Principles 

Livelnventor was designed with a number of 
principles in mind. The first was integrate rather 
than reinvent, that is, wherever possible use 
existing software and file formats rather than 
writing our own. Not only does this save time 
but it also frees the user from having to learn yet 
another proprietary language and/or file format. 
Livelnventor’ s file format will be quite familiar 
to anyone familiar with VRML. The second 
principle was to use open source wherever 
* possible. All components of Livelnventor are 
open source except for the Vortex simulation 
engine, and we are looking into developing a 
version of Livelnventor that uses an open source 
simulation engine like ODE [4]. Using open 
source makes redistribution to academic 
institutions much simpler. A third principle was 
to make it scalable. We wanted it to be easy for 
Livelnventor users to throw together a small 
mechanical simulation, while still being able to 
simulate and render large, complex environments 
like the International Space Station. Our fourth 
principle was portability through portable 
components. All the individual components 
comprising Openlnventor run on Linux as well 
as Microsoft Windows, so porting it to Linux is 
just a matter of recompiling and linking on 
Linux. 

Current customers and future 
directions 

Livelnventor is currently being used by the 
Personal Satellite Assistant project to simulate 
the interaction of the PSA with astronauts inside 
the International Space Station. In this scenario 
Livelnventor must simulate the PSA in real time 
because it is being controlled by the same 



software that will ultimately control the 
‘ hardware PSA. The PSA controller 
communicates with Livelnventor over CORBA; 
integration of Livelnventor with the CORBA 
controller took an afternoon. 

Livelnventor is also being used to 
develop and test diagnostic code for the K9 rover 
arm. Richard Dearden’s group at Ames is 
developing a system to perform mode and 
parameter estimation to improve the robustness 
of rover traverses and instrument placement. 
They are getting a copy of the K9 robotic arm 
and a workspace or 'mini Mars yard’ surrounding 
the arm. Its purpose is to increase access to a 
limited resource (the single arm on K9) and to 
enable the insertion of faulty components 
without impacting the main K9 rover. The 
team’s ability to achieve both of these goals can 
be significantly enhanced through a software 
simulation of the arm. A simulation can be ready 
earlier and enable exploration of a greater range 
of parameter values, workspace configurations, 
and inserted faults at some cost in fidelity. 

Potential directions include large-scale 
massively parallel simulations to coevolve 
hardware and controllers, use by mission 


operations to simulate traversals and tasks to 
detect potential problems, and integration of 
physical simulation and modeling into a rover's 
onboard software path-planning software. 
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